home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / bfl / bfl.lha / cfortran.doc < prev    next >
Text File  |  1992-10-28  |  63KB  |  1,370 lines
  1. /* cfortran.doc */            /* anonymous ftp: zebra.desy.de */
  2. /* Burkhard Burow, burow@vxdesy.cern.ch, U. of Toronto, 1992. */
  3.  
  4.  
  5.                  cfortran.h 2.4  :  Interfacing C and FORTRAN
  6.  
  7. Supports: VAX VMS or Ultrix, DECstation, Silicon Graphics, IBM RS/6000, Sun, 
  8.           CRAY, Apollo, HP9000, LynxOS, f2c, NAG f90.
  9.  
  10.  
  11.  
  12. 0 Short Summary of the Syntax Required to Create the Interface
  13. --------------------------------------------------------------
  14.  
  15. e.g. Prototyping a FORTRAN subroutine for C: [other argument types.]
  16.                                - -
  17.                               | 0 |
  18.                               | 1 |
  19.                                - -
  20. #define SUB_NAME(A,B) CCALLSFSUB2(SUB_NAME,sub_name,STRING,PINT, A,B)
  21.                                - -    -                                       -
  22.                               | 3 |  |   STRING   BYTE    PBYTE       BYTEV(V) |
  23.                               | 4 |  |   STRINGV  DOUBLE  PDOUBLE   DOUBLEV(V) |
  24.                               | : |  |  PSTRING   FLOAT   PFLOAT     FLOATV(V) |
  25.                               | : |  |  PSTRINGV  INT     PINT         INTV(V) |
  26.                               |19 |  |   ZTRINGV  LOGICAL PLOGICAL LOGICALV(V) |
  27.                               |20 |  |  PZTRINGV  LONG    PLONG       LONGV(V) |
  28.                               | : |  |            SHORT   PSHORT     SHORTV(V) |
  29.                               | : |  |  PVOID     SIMPLE                       |
  30.                                - -    -                                       -
  31.  
  32. e.g. Prototyping a FORTRAN function for C:
  33. PROTOCCALLSFFUN1(INT,FUN_NAME,fun_name,STRING)
  34. #define FUN_NAME(A)  CCALLSFFUN1(FUN_NAME,fun_name,STRING, A)
  35.  
  36. e.g. calling FUN_NAME from C:    {int a; a = FUN_NAME("hello");}
  37.  
  38. e.g. Creating a FORTRAN-callable wrapper for a C function returning void:
  39. FCALLSCSUB1(csub_name,CSUB_NAME,csub_name,STRING)
  40.  
  41. e.g. Creating a FORTRAN-callable wrapper for other C functions:
  42. FCALLSCFUN1(STRING,cfun_name,CFUN_NAME,cfun_name,INT)
  43.            [ ^-- BYTE, DOUBLE, FLOAT, INT, LOGICAL, LONG, SHORT, VOID  
  44.              are other types returned by functions.       ]
  45.        
  46. e.g. COMMON BLOCKs:
  47. FORTRAN:                         common /fcb/  v,w,x
  48.                                  character *(13) v, w(4), x(3,2)
  49. C:
  50. typedef struct { char v[13],w[4][13],x[2][3][13]; } FCB_DEF;
  51. #define FCB COMMON_BLOCK(FCB,fcb)
  52. COMMON_BLOCK_DEF(FCB_DEF,FCB);
  53.  
  54. e.g. accessing FCB in C:          printf("%.13s",FCB.v);
  55.  
  56.  
  57.  
  58. I Introduction
  59. --------------
  60.  
  61. cfortran.h is an easy-to-use powerful bridge between C and FORTRAN. It provides
  62. a completely transparent, machine independent interface between C and FORTRAN
  63. routines (= subroutines and/or functions) and global data, i.e. structures and
  64. COMMON blocks.
  65.  
  66. The complete cfortran.h package consists of 4 files: the documentation in
  67. cfortran.doc, the engine cfortran.h, examples in cfortest.c and 
  68. cfortex.f/or. [cfortex.for under VMS, cfortex.f on other machines.]
  69.  
  70. The cfortran.h package continues to be developed. The most recent version is
  71. available via anonymous ftp at zebra.desy.de (131.169.2.244).
  72.  
  73. The examples may be run using one of the following sets of instructions:
  74. [The first set of instructions is also required with, and only with, ANSI C.]
  75.  
  76. ANSI> # cfortran.h is distributed with the /**/ prepro-token-catenation kludge.
  77. ANSI> # To make cfortran.h ANSI compliant and for it to run on:
  78. ANSI> # -- RS/6000, CRAY, Apollo C >=Rev6.8, LynxOS, gcc, SGI ANSI C --------
  79. ANSI> # -------------------- and other ANSI C compilers ---------------------
  80. ANSI> # --------- [Non-ANSI compilers CAN NOT use an ANSI cfortran.h.] ------
  81. ANSI> # do the following once to cfortran.h: 
  82. ANSI> mv cfortran.h cf_temp.h &&sed 's/\/\*\*\//##/g' cf_temp.h >cfortran.h
  83.  
  84. RS/6000> xlf -c cfortex.f
  85. RS/6000> cc  -c cfortest.c && xlf -o cfortest cfortest.o cfortex.o  &&  cfortest
  86.  
  87. DECFortran> #Only DECstations with DECFortran for Ultrix RISC Systems.
  88. DECFortran> cc -c -DDECFortran cfortest.c
  89. DECFortran> f77 -o cfortest cfortest.o cfortex.f  &&  cfortest
  90.  
  91. MIPS> # DECstations and Silicon Graphics using the MIPS compilers.
  92. MIPS> cc -o cfortest cfortest.c cfortex.f -lI77 -lU77 -lF77  &&  cfortest
  93.  
  94. Apollo> # Some 'C compiler 68K Rev6.8' break. [See Section II o) Notes: Apollo]
  95. Apollo> f77 -c cfortex.f && cc -o cfortest cfortest.c cfortex.o  &&  cfortest
  96.  
  97. VMS> define lnk$library sys$library:vaxcrtl
  98. VMS> cc cfortest.c
  99. VMS> fortran cfortex.for
  100. VMS> link/exec=cfortest cfortest,cfortex
  101. VMS> run cfortest
  102.  
  103. Sun> # Some old cc(1) need a little help. [See Section II o) Notes: Sun]
  104. Sun> f77 -o cfortest cfortest.c cfortex.f -lc -lm  &&  cfortest
  105.  
  106. CRAY> cft77 cfortex.f
  107. CRAY> cc -c cfortest.c
  108. CRAY> segldr -o cfortest.e cfortest.o cfortex.o
  109. CRAY> ./cfortest.e
  110.  
  111. VAX/Ultrix/cc> # For cc on VAX Ultrix only, do the following once to cfortran.h.
  112. VAX/Ultrix/cc> mv cfortran.h cftmp.h && grep -v "^#pragma" <cftmp.h >cfortran.h
  113.                                             
  114. VAX/Ultrix/f77> # In the following, 'CC' is either 'cc' or 'gcc -ansi'. NOT'vcc'
  115. VAX/Ultrix/f77> CC -c -Dmain=MAIN_ cfortest.c
  116. VAX/Ultrix/f77> f77 -o cfortest cfortex.f cfortest.o  &&  cfortest
  117.  
  118. LynxOS> # In the following, 'CC' is either 'cc' or 'gcc -ansi'.
  119. LynxOS> # Unfortunately cc is easily overwhelmed by cfortran.h,
  120. LynxOS> #  and won't compile some of the cfortest.c demos.
  121. LynxOS> f2c cfortex.f
  122. LynxOS> CC -Dlynx -o cfortest cfortest.c cfortex.c -lf2c  &&  cfortest
  123.  
  124. HP9000> # Tests have been done only with HP-UX 7.05 B 9000/380.
  125. HP9000> f77 -c cfortex.f
  126. HP9000> cc -o cfortest cfortest.c cfortex.o -lI77 -lF77  &&  cfortest
  127.  
  128. f2c> # In the following, 'CC' is any C compiler.
  129. f2c> f2c cfortex.f
  130. f2c> CC -o cfortest -Df2cFortran cfortest.c cfortex.c -lf2c  &&  cfortest
  131.  
  132. NAGf90> # cfortex.f is distributed with Fortran 77 style comments.
  133. NAGf90> # To convert to f90 style comments do the following once to cfortex.f: 
  134. NAGf90> mv cfortex.f cf_temp.f && sed 's/^C/\!/g' cf_temp.f > cfortex.f
  135. NAGf90> # In the following, 'CC' is any C compiler.
  136. NAGf90> CC -c -DNAGf90Fortran cfortest.c
  137. NAGf90> f90 -o cfortest cfortest.o cfortex.f &&  cfortest
  138.  
  139.  
  140. By changing the SELECTion ifdef of cfortest.c and recompiling one can try out
  141. two dozen different few-line examples.
  142.  
  143.  
  144.  
  145. The benefits of using cfortran.h include:
  146. 1. Machine/OS/compiler independent mixing of C and FORTRAN.
  147.  
  148. 2. Identical (within syntax) calls across languages, e.g.
  149. C FORTRAN
  150.       CALL HBOOK1(1,'pT spectrum of pi+',100,0.,5.,0.)
  151. /* C*/
  152.            HBOOK1(1,"pT spectrum of pi+",100,0.,5.,0.);
  153.  
  154. 3. Each routine need only be set up once in its lifetime. e.g.
  155. /* Setting up a FORTRAN routine to be called by C. Note that ID,...,VMX are
  156. merely the names of arguments. These tags must be unique w.r.t. each other but 
  157. are arbitrary. */
  158. #define HBOOK1(ID,CHTITLE,NX,XMI,XMA,VMX)                    \
  159.  CCALLSFSUB6(HBOOK1,hbook1,INT,STRING,INT,FLOAT,FLOAT,FLOAT, \
  160.                ID,CHTITLE,NX,XMI,XMA,VMX) 
  161.  
  162. 4. Source code is NOT required for the C routines exported to FORTRAN, nor for
  163.    the FORTRAN routines imported to C. In fact, routines are most easily
  164.    prototyped using the information in the routines' documentation.
  165.  
  166. 5. Routines, and the code calling them, can be coded naturally in the language
  167.    of choice. C routines may be coded with the natural assumption of being 
  168.    called only by C code. cfortran.h does all the required work for FORTRAN 
  169.    code to call C routines. Similarly it also does all the work required for C
  170.    to call FORTRAN routines. Therefore:
  171.      - C programmers need not embed FORTRAN argument passing mechanisms into 
  172.        their code.
  173.      - FORTRAN code need not be converted into C code. i.e. The honed and 
  174.        time-honored FORTRAN routines are called by C.
  175.  
  176. 6. cfortran.h is a single ~1400 line C include file; portable to most
  177.    remaining, if not all, platforms.
  178.  
  179. 7. STRINGS and VECTORS of STRINGS along with the usual simple arguments to 
  180.    routines are supported as are functions returning STRINGS or numbers. Arrays
  181.    of pointers to strings and values of structures as C arguments, will soon be
  182.    implemented. After learning the machinery of cfortran.h, users can expand 
  183.    it to create custom types of arguments. [Note that this requires no 
  184.    modification to cfortran.h, all the preprocessor directives required to
  185.    implement the custom types can be defined outside cfortran.h]
  186.  
  187. 8. cfortran.h requires each routine to be exported to be explicitly set up. 
  188.    While is usually only be done once in a header file it would be best if
  189.    applications were required to do no work at all in order to cross languages.
  190.    cfortran.h's simple syntax could be a convenient back-end for a program
  191.    which would export FORTRAN or C routines directly from the source code. 
  192.  
  193.  
  194.                                     -----
  195.  
  196. Example 1 - cfortran.h has been used to make the C header file hbook.h, 
  197.             which then gives any C programmer, e.g. example.c, full and 
  198.             completely transparent access to CERN's HBOOK library of routines.
  199.             Each HBOOK routine required about 3 lines of simple code in
  200.             hbook.h. The example also demonstrates how FORTRAN common blocks
  201.             are defined and used.
  202.  
  203. /* hbook.h */
  204. #include "cfortran.h"
  205.         :
  206. #define HBOOK1(ID,CHTITLE,NX,XMI,XMA,VMX) \
  207.      CCALLSFSUB6(HBOOK1,hbook1,INT,STRING,INT,FLOAT,FLOAT,FLOAT, \
  208.                ID,CHTITLE,NX,XMI,XMA,VMX) 
  209.         :
  210. /* end hbook.h */
  211.  
  212. /* example.c */
  213. #include "hbook.h"
  214.         :
  215. typedef struct {
  216.   int lines;  
  217.   int status[SIZE];
  218.   float p[SIZE];  /* momentum */
  219. } FAKE_DEF;
  220. #define FAKE COMMON_BLOCK(FAKE,fake)
  221. COMMON_BLOCK_DEF(FAKE_DEF,FAKE);
  222.         :
  223. main ()
  224. {
  225.         :
  226.            HBOOK1(1,"pT spectrum of pi+",100,0.,5.,0.);
  227. /* c.f. the call in FORTRAN:
  228.       CALL HBOOK1(1,'pT spectrum of pi+',100,0.,5.,0.)
  229. */
  230.         :
  231.   FAKE.p[7]=1.0;
  232.     :
  233. }           
  234.  
  235. N.B. i) The routine is language independent.
  236.     ii) hbook.h is machine independent.  
  237.    iii) Applications using routines via cfortran.h are machine independent.
  238.  
  239.                                     -----
  240.  
  241. Example 2 - Many VMS System calls are most easily called from FORTRAN, but
  242.             cfortran.h now gives that ease in C.
  243.  
  244. #include "cfortran.h"
  245.  
  246. #define LIB$SPAWN(command,input_file,output_file) \
  247.      CCALLSFSUB3(LIB$SPAWN,lib$spawn,STRING,STRING,STRING, \
  248.                   command,input_file,output_file)
  249.  
  250. main ()
  251. {
  252. LIB$SPAWN("set term/width=132","","");
  253. }
  254.  
  255. Obviously the cfortran.h command above could be put into a header file along
  256. with the description of the other system calls, but as this example shows, it's
  257. not much hassle to set up cfortran.h for even a single call.
  258.  
  259.                                     -----
  260.  
  261. Example 3 - cfortran.h and the source cstring.c create the cstring.obj library 
  262.             which gives FORTRAN access to all the functions in C's system 
  263.             library described by the system's C header file string.h.
  264.  
  265. C     EXAMPLE.FOR
  266.       PROGRAM EXAMPLE
  267.       DIMENSION I(20), J(30)
  268.         :
  269.       CALL MEMCPY(I,J,7)
  270.         :
  271.       END
  272.  
  273. /* cstring.c */
  274. #include <string.h>             /* string.h prototypes memcpy() */
  275. #include "cfortran.h"
  276.  
  277.         :
  278. FCALLSCSUB3(memcpy,MEMCPY,memcpy,PVOID,PVOID,INT)
  279.         :
  280.  
  281.  
  282. The simplicity exhibited in the above example exists for many but not all
  283. machines. Note 4. of Section II ii) details the limitations and describes tools
  284. which try to maintain the best possible interface when FORTRAN calls C
  285. routines.
  286.  
  287.                                     -----
  288.  
  289.  
  290. II Using cfortran.h
  291. -------------------
  292.  
  293. The user is asked to look at the source files CFORTEST.C and CFORTEX.FOR for
  294. clarification by example.
  295.  
  296. o) Notes: 
  297.  
  298. o Specifying the Fortran compiler
  299.   cfortran.h generates interfaces for the default Fortran compiler. The default
  300. can be overridden by defining, 
  301.   . either in your code, e.g.          #define    NAGf90Fortran
  302.   . or in the compile directive, e.g.: unix> cc -DNAGf90Fortran
  303. one of the following before including cfortran.h:
  304.  NAGf90Fortran   f2cFortran  hp9000s300Fortran  apolloFortran  sunFortran
  305.   IBMR2Fortran  CRAYFortran        mipsFortran     DECFortran  vmsFortran
  306. This also allows crosscompilation.
  307.   Note that  NAGf90Fortran   f2cFortran  DECFortran
  308. must be requested if wanted by the user.
  309.  
  310. o LOGICAL
  311.   FORTRAN LOGICAL values of .TRUE. and .FALSE. do not agree with the C
  312. representation of TRUE and FALSE on all machines. cfortran.h does the
  313. conversion for LOGICAL and PLOGICAL arguments and for functions returning
  314. LOGICAL. Users must convert arrays of LOGICALs from C to FORTRAN with the 
  315. C2FLOGICALV(array_name, elements_in_array); macro. Similarly, arrays of LOGICAL
  316. values may be converted from the FORTRAN into C representation by using
  317. F2CLOGICALV(array_name, elements_in_array);
  318.  
  319.   When C passes or returns LOGICAL values to FORTRAN, by default cfortran.h 
  320. only makes the minimal changes required to the value. [e.g. Set/Unset the 
  321. single relevant bit or do nothing for FORTRAN compilers which use 0 as FALSE
  322. and treat all other values as TRUE.] Therefore cfortran.h will pass LOGICALs
  323. to FORTRAN which do not have an identical representation to .TRUE. or .FALSE.
  324. This is fine except for abuses of FORTRAN/77 in the style of:
  325.        logical l
  326.        if (l .eq. .TRUE.)     ! (1)
  327. instead of the correct:
  328.        if (l .eqv. .TRUE.)    ! (2)
  329. or:
  330.        if (l)                 ! (3)
  331. For FORTRAN code which treats LOGICALs from C in the method of (1),
  332. LOGICAL_STRICT must be defined before including cfortran.h, either in your
  333. code, "#define LOGICAL_STRICT", or compile with "cc -DLOGICAL_STRICT".
  334. There is no reason to use LOGICAL_STRICT for FORTRAN code which does not do
  335. (1), and note that at least the IBM's xlf and the Apollo's f77 do not allow
  336. code along the lines of (1).
  337.  
  338.   DECstations' DECFortran and MIPS FORTRAN compilers use different internal
  339. representations for LOGICAL values. [Both compilers are usually called f77,
  340. although when both are installed on a single machine the MIPS' one is usually
  341. renamed. (e.g. f772.1 for version 2.10.)] cc doesn't know which FORTRAN
  342. compiler is present, so cfortran.h assumes MIPS f77. To use cc wth DECFortran
  343. define the preprocessor constant 'DECFortran'.
  344. e.g.        i)  cc -DDECFortran -c your_code.c
  345.         or  ii) #define DECFortran  /* in your C code or add to cfortran.h. */
  346.  
  347.   MIPS f77 [SGI and DECstations], f2c, and f77 on VAX Ultrix treat
  348. .eqv./.neqv. as .eq./.ne.. Therefore, for these compilers, LOGICAL_STRICT is
  349. defined by default in cfortran.h. [The Sun and HP compilers have not been
  350. tested, so they may also require LOGICAL_STRICT as the default.]
  351.  
  352. o SHORT and BYTE are irrelevant for the CRAY where FORTRAN has no equivalent to
  353. C's short. Similarly BYTE is irrelevant for f2c and for VAX Ultrix f77 and
  354. fort. The author has tested SHORT and BYTE with a modified cfortest.c/cfortex.f
  355. on all machines supported except for the HP9000 and the Sun. The author will
  356. e-mail the modified cfortest.c/cfortex.f to anyone who wishes to test SHORT
  357. and/or BYTE. 
  358.  
  359.   BYTE is a signed 8-bit quantity, i.e. values are -128 to 127, on all machines
  360. except for the SGI [at least for MIPS Computer Systems 2.0.] On the SGI it is
  361. an unsigned 8-bit quantity, i.e. values are 0 to 255, although the SGI 'FORTRAN
  362. 77 Programmers Guide' claims BYTE is signed. Perhaps MIPS 2.0 is dated, since
  363. the DECstations using MIPS 2.10 f77 have a signed BYTE.
  364.  
  365.   To minimize the difficulties of signed and unsigned BYTE, cfortran.h creates
  366. the type 'INTEGER_BYTE' to agree with FORTRAN's BYTE. Users may define 
  367. SIGNED_BYTE or UNSIGNED_BYTE, before including cfortran.h, to specify FORTRAN's
  368. BYTE. If neither is defined, cfortran.h assumes SIGNED_BYTE.
  369.  
  370. o The type DOUBLE in cfortran.h corresponds to FORTRAN's DOUBLE PRECISION.
  371. This implies DOUBLE corresponds to C's double on all machines except for the
  372. CRAY where C's double is the same as float and DOUBLE corresponds instead to
  373. C's long double. Therefore when moving a mixed C and FORTRAN to/from the CRAY,
  374. either the C code will have to change, or the FORTRAN code and cfortran.h
  375. commands will have to change.
  376.  
  377. To help applications move effortlessly to/from the CRAY, cfortran.h defines the
  378. preprocessor constant DOUBLE_PRECISION, which declares variables which are
  379. equivalent to FORTRAN's DOUBLE PRECISION on all machines, including CRAY.
  380.  
  381. o cfortran.h (ab)uses the null comment kludge, /**/, for the ANSI C
  382. preprocessor concatenation operator, ##. In at least MIPS C this kludge is
  383. sensitive to  blanks surrounding arguments to macros.
  384.  
  385. Therefore, for applications using non-ANSI C compilers, the argtype_i,
  386. routine_name, routine_type and common_block_name arguments to the
  387. PROTOCCALLSFFUNn, CCALLSFSUB/FUNn, FCALLSCSUB/FUNn and COMMON_BLOCK macros 
  388. --- MUST NOT --- be surrounded by any whitespace characters, [e.g. blanks,
  389. tabs, newlines.]
  390.  
  391. o NAG f90
  392.   The Fortran 77 subset of Fortran 90 is supported. Extending cfortran.h to 
  393. interface C with all of Fortran 90 has not yet been examined.
  394.   The NAG f90 library hijacks the main() of any program and starts the user's 
  395. program with a call to: void f90_main(void);
  396. While this in itself is only a minor hassle, a major problem arises because
  397. NAG f90 provides no mechanism to access command line arguments.
  398.  
  399. o On the RS/6000, using "xlf -qextname ...", which appends an underscore, '_',
  400. to all FORTRAN external references, requires "cc -Dextname ..." so that
  401. cfortran.h also generates these underscores.
  402.  
  403. o Apollo:
  404. On at least one release, 'C compiler 68K Rev6.8(168)', the default C 
  405. preprocessor, from cc -A xansi or cc -A ansi, enters an infinite loop when 
  406. using cfortran.h. This Apollo bug can be circumvented by using:
  407.  . The standard cfortran.h, i.e. do not convert the '/**/' to '##'. 
  408.  . The pre-ANSI preprocessor, i.e. use cc -Yp,/usr/lib
  409.  
  410. o Sun:
  411. Old versions of cc(1), say <~1986, may require help for cfortran.h applications:
  412.  . #pragma may not be understood, hence do the following once to cfortran.h.
  413.    sun> mv cfortran.h cftmp.h && grep -v "^#pragma" <cftmp.h >cfortran.h
  414.  . Old copies of math.h may not include the following from a newer math.h.
  415.    [For an ancient math.h on a 386 or sparc, get similar from a new math.h.]
  416.    #ifdef mc68000     /* 5 lines Copyright (c) 1988 by Sun Microsystems, Inc. */
  417.    #define FLOATFUNCTIONTYPE    int
  418.    #define RETURNFLOAT(x)         return (*(int *)(&(x)))
  419.    #define ASSIGNFLOAT(x,y)    *(int *)(&x) = y
  420.    #endif
  421.  
  422. o On the CRAY, Sun, Apollo [pre 6.8 cc], VAX Ultrix and HP9000, only FORTRAN
  423. routines with less than 15 arguments can be prototyped for C, since these
  424. compilers don't allow more than 31 arguments to a C macro. This can be
  425. overcome, [see Section IV], with access to any C compiler without this
  426. limitation, e.g. gcc, on ANY machine.
  427.  
  428. o VAX Ultrix only:
  429.   vcc (1) with f77 is not supported. Although: 
  430. VAXUltrix> f77 -c cfortex.f
  431. VAXUltrix> vcc -o cfortest cfortest.c cfortex.o -lI77 -lU77 -lF77  &&  cfortest
  432. will link and run. However, the FORTRAN standard I/O is NOT merged with the
  433. stdin and stdout of C, and instead uses the files fort.6 and fort.5. For vcc,
  434. f77 can't drive the linking, as for gcc and cc, since vcc objects must be
  435. linked using lk (1).  f77 -v doesn't tell much, and without VAX Ultrix manuals,
  436. the author can only wait for the info. required.
  437.  
  438.   fort (1) is not supported. Without VAX Ultrix manuals the author cannot 
  439. convince vcc/gcc/cc and fort to generate names of routines and COMMON blocks
  440. that match at the linker, lk (1). i.e. vcc/gcc/cc prepend a single underscore
  441. to external references, e.g. NAME becomes _NAME, while fort does not modify the
  442. references. So ... either fort has prepend an underscore to external
  443. references, or vcc/gcc/cc have to generate unmodified names. man 1 fort
  444. mentions JBL, is JBL the only way?
  445.  
  446. o The VAX VMS C compiler 'easily' exhausts its table space and generates:
  447. %CC-F-BUGCHECK, Compiler bug check during parser phase    .
  448.                 Submit an SPR with a problem description.
  449.                 At line number 777 in DISK:[DIR]FILE.C;1.
  450. where the line given, '777', includes a call across C and FORTRAN via
  451. cfortran.h, usually with >7 arguments and/or very long argument expressions.
  452. This SPR can be staved off, with the simple modification to cfortran.h, such
  453. that the relevant CCALLSFSUBn (or CCALLSFFUNn or FCALLSCFUNn) is not
  454. cascaded up to CCALLSFSUB14, and instead has its own copy of the contents of 
  455. CCALLSFSUB14. [If these instructions are not obvious after examining cfortran.h
  456. please contact the author.]
  457. [Thanks go to Mark Kyprianou (kyp@stsci.edu) for this solution.]
  458.  
  459. o The Mips compilers, e.g. DECstations and SGI, require applications with a C
  460. main() and calls to GETARG(3F), i.e. FORTRAN routines returning the command
  461. line arguments, to use two macros as shown:
  462.         :
  463. CF_DECLARE_GETARG;              /* This must be external to all routines.     */
  464.         :
  465. main(int argc, char *argv[])
  466. {
  467.         :
  468. CF_SET_GETARG(argc,argv);       /* This must precede any calls to GETARG(3F). */
  469.         :
  470. }
  471.  
  472. The macros are null and benign on all other systems. Sun's GETARG(3F) also
  473. doesn't work with a generic C main() and perhaps a workaround similar to the
  474. Mips' one exists.
  475.  
  476. o The FORTRAN routines are called using macro expansions, therefore the usual
  477. caveats for expressions in arguments apply. The expressions to the routines may
  478. be evaluated more than once, leading to lower performance and in the worst case
  479. bizarre bugs.
  480.  
  481. o Not supported:
  482. - C calling FORTRAN functions with (P)ZTRINGV arguments, can't have as an
  483.   argument a call to a FORTRAN function with (P)ZTRINGV arguments. 
  484. - Similarly disallowed is nesting of C calls to any FORTRAN functions with
  485.   (P)ZTRINGV arguments, recursive [which is an extension to FORTRAN/77], or 
  486.   otherwise.
  487. [The restrictions are actually less severe, but these are sufficient.]
  488.  
  489. o For those who wish to use cfortran.h in large applications. [See Section IV.]
  490. This release is intended to make it easy to get applications up and running. 
  491. This implies that applications are not as efficient as they could be:
  492. - The current mechanism is inefficient if a single header file is used to
  493.   describe a large library of FORTRAN functions. Code for a static wrapper fn.
  494.   is generated in each piece of C source code for each FORTRAN function 
  495.   specified with the CCALLSFFUNn statement, irrespective of whether or not the
  496.   function is ever called. 
  497. - Code for several static utility routines internal to cfortran.h is placed 
  498.   into any source code which #includes cfortran.h. These routines should
  499.   probably be in a library.
  500.  
  501.  
  502. i) Calling FORTRAN routines from C:
  503.    --------------------------------
  504.  
  505. FORTRAN FUNCTIONs are prototyped by the following macro.
  506. [Note that FORTRAN SUBROUTINEs don't require a similar instruction.]
  507.  
  508. PROTOCCALLSFFUNn(routine_type,ROUTINE_NAME,routine_name,argtype_1,...,argtype_n)
  509.  
  510.  
  511. The FORTRAN routines are defined by one of the following two instructions.
  512.  
  513. for a SUBROUTINE:
  514. #define     Routine_name(argname_1,..,argname_n)               \
  515. CCALLSFSUBn(ROUTINE_NAME,routine_name,argtype_1,...,argtype_n, \
  516.                          argname_1,..,argname_n) 
  517.  
  518. for a FUNCTION:
  519. #define     Routine_name(argname_1,..,argname_n)               \
  520. CCALLSFFUNn(ROUTINE_NAME,routine_name,argtype_1,...,argtype_n, \
  521.                          argname_1,..,argname_n) 
  522.  
  523. Where:
  524. 'n' = 0->10 [SUBROUTINE's ->20] (easily expanded in cfortran.h to > 10 [20]) is 
  525.     the number of arguments to the routine.
  526. Routine_name = C       name of the routine (IN UPPER CASE LETTERS).[see 2.below]
  527. ROUTINE_NAME = FORTRAN name of the routine (IN UPPER CASE LETTERS).
  528. routine_name = FORTRAN name of the routine (IN lower case LETTERS).
  529. routine_type = the type of argument returned by FORTRAN functions.
  530.              = BYTE, DOUBLE, FLOAT, INT, LOGICAL, LONG, SHORT, STRING, VOID.
  531.                [Instead of VOID one would usually use CCALLSFSUBn.
  532.                 VOID forces a wrapper function to be used.]
  533. argtype_i    = the type of argument passed to the FORTRAN routine and must be
  534.                consistent in the definition and prototyping of the routine s.a.
  535.              = BYTE, DOUBLE, FLOAT, INT, LOGICAL, LONG, SHORT, STRING.
  536.              For vectors, i.e. 1 dim. arrays use 
  537.              = BYTEV, DOUBLEV, FLOATV, INTV, LOGICALV, LONGV, SHORTV, 
  538.                STRINGV, ZTRINGV.
  539.              For vectors of vectors, 2 dim. arrays use
  540.              = BYTEVV, DOUBLEVV, FLOATVV, INTVV, LOGICALVV, LONGVV, SHORTVV.
  541.              For n-dim. arrays use [currently implement n=1,2. n>2 easily done.]
  542.              = BYTEV..nV's..V, DOUBLEV..V, FLOATV..V, INTV..V, LOGICALV..V, 
  543.                LONGV..V, SHORTV..V.
  544.                 N.B. Array dimensions and types are checked by the C compiler.
  545.              For routines changing the values of an argument, the keyword is 
  546.                   prepended by a 'P'.
  547.              = PBYTE, PDOUBLE, PFLOAT, PINT, PLOGICAL, PLONG, PSHORT,
  548.                PSTRING, PSTRINGV, PZTRINGV.
  549.              For exceptional arguments which require no massaging to fit the
  550.                   argument passing mechanisms use:
  551.              = PVOID.
  552.                 This is most useful for passing functions as arguments.
  553.                 But note that although PVOID could be used to describe all
  554.                 array arguments on most (all?) machines , it shouldn't be
  555.                 because the C compiler can no longer check the type and 
  556.                 dimension of the array.
  557. argname_i    = any valid unique C tag, but must be consistent in the definition 
  558.                as shown.
  559.  
  560. Notes:
  561.  
  562. 1. cfortran.h may be expanded to handle a more argument type. To suppport new
  563. arguments requiring complicated massaging when passed  between Fortran and C,
  564. the user will have to understand cfortran.h and follow its code and mechanisms.
  565.  
  566. To define types requiring little or no massaging when passed between Fortran 
  567. and C, the pseudo argument type SIMPLE may be used.
  568. For a user defined type called 'newtype', the definitions required are:
  569.  
  570. /* The follwing 8 lines are required verbatim, 'newtype' is the name of the 
  571. new user defined argument type.
  572. */
  573. #define Vnewtype              VSIMPLE
  574. #define SEP_newtype        SEP_SIMPLE
  575. #define INT_newtype        INT_SIMPLE
  576. #define Znewtype              ZSIMPLE
  577. #define STR_newtype        STR_SIMPLE
  578. #define CCnewtype            CCSIMPLE
  579. #define AAnewtype( T,A,B)     Bnewtype(T,A)   /* Argument B is not used here. */
  580. #define Unewtype(  T,A)       Nnewtype(T) (A) /* Argument B is not used here. */
  581.  
  582. /* 'parameter_type' is the type of the parameter expected by the Fortran
  583. function.  This type will be used in the prototype for the function, if  using
  584. ANSI C, and to declare the argument used by the intermediate function if
  585. calling a Fortran FUNCTION.
  586. */
  587. #define Nnewtype(  T)       parameter_type    /* Argument T is not used here. */
  588.  
  589. /* Before any argument of the new type is passed to the Fortran routine, it may
  590. be massaged as given by 'massage(A)'.
  591. */
  592. #define Bnewtype(  T,A)     massage(A)        /* Argument T is not used here. */
  593.  
  594. An example of a simple user defined type is given cfortex.for and cfortest.c.
  595. Two uses of SIMPLE user defined types are [don't show the 8 verbatim #defines]:
  596.  
  597. /* Pass the address of a structure, using a type called PSTRUCT */
  598. #define NPSTRUCT(  T)          void *
  599. #define BPSTRUCT(  T,A)       (void *) &(A)
  600.  
  601. /* Pass an integer by value, (not standard F77 ), using a type called INTVAL */
  602. #define NINTVAL(  T)           int
  603. #define BINTVAL(  T,A)         (A)
  604.  
  605. [If using VAX VMS, surrounding the #defines with "#pragma (no)standard" allows
  606.  the %CC-I-PARAMNOTUSED messages to be avoided.]
  607.  
  608. Upgrades to cfortran.h try to be, and have been, backwards compatible. This
  609. compatibility cannot be offered to user defined types. SIMPLE user defined 
  610. types are less of a risk since they require so little effort in their creation.
  611. If a user defined type is required in more than one C header file of interfaces
  612. to libraries of Fortran routines, good programming practice, and ease of code
  613. maintenance, suggests keeping any user defined type within a single file which
  614. is #included as required.
  615.  
  616.  
  617. 2. Routine_name is the name of the macro which the C programmer will use in
  618. order to call a FORTRAN routine. In theory Routine_name could be any valid and
  619. unique name, but in practice, the name of the FORTRAN routine in UPPER CASE
  620. works everywhere and would seem to be an obvious choice.
  621.  
  622.  
  623. 3. <BYTE|DOUBLE|BYTE|DOUBLE|FLOAT|INT|LOGICAL|LONG|SHORT><V|VV|VVV|...>
  624.  
  625. cfortran.h encourages the exact specification of the type and dimension of
  626. array parameters because it allows the C compiler to detect errors in the
  627. arguments when calling the routine.
  628.  
  629. cfortran.h does not strictly require the exact specification since the argument 
  630. is merely the address of the array and is passed on to the calling routine.
  631. Any array parameter could be declared as PVOID, but this circumvents
  632. C's compiletime ability to check the correctness of arguments and is therefore
  633. discouraged.
  634.  
  635. Passing the address of these arguments implies that PBYTEV, PFLOATV, ... ,
  636. PDOUBLEVV, ... don't exist in cfortran.h, since by default the routine and the
  637. calling code share the same array, i.e. the same values at the same memory
  638. location.
  639.  
  640. These comments do NOT apply to arrays of (P)S/ZTRINGV. For these parameters,
  641. cfortran.h passes a massaged copy of the array to the routine. When the routine
  642. returns, S/ZTRINGV ignores the copy, while PS/ZTRINGV replaces the calling
  643. code's original array with copy, which may have been modified by the called
  644. routine.
  645.  
  646.  
  647. 4. (P)STRING(V):
  648. - STRING - If the argument is a fixed length character array, e.g. char ar[8];,
  649. the string is blank, ' ', padded on the right to fill out the array before
  650. being passed to the FORTRAN routine. The useful size of the string is the same
  651. in both languages, e.g. ar[8] is passed as character*7. If the argument is a
  652. pointer, the string cannot be blank padded, so the length is passed as
  653. strlen(argument). On return from the FORTRAN routine, pointer arguments are not
  654. disturbed, but arrays have the terminating '\0' replaced to its original
  655. position. i.e. The padding blanks are never visible to the C code.
  656.  
  657. - PSTRING - The argument is massaged as with STRING before being passed to the
  658. FORTRAN routine. On return, the argument has all trailing blanks removed,
  659. regardless of whether the argument was a pointer or an array.
  660.  
  661. - (P)STRINGV - Only supports char arrays. e.g. char bb[6][8];
  662.  
  663. - STRINGV - The elements of the argument are copied into space malloc'd, and
  664. each element is padded with blanks. The useful size of each element is the same
  665. in both languages. Therefore char bb[6][8]; is equivalent to character*7 bb(6).
  666. On return from the routine the malloc'd space is simply released.
  667.  
  668. - PSTRINGV - Since FORTRAN has no trailing '\0', elements in an array of
  669. strings are contiguous. Therefore each element of the C array is padded with
  670. blanks and strip out C's trailing '\0'. After returning from the routine, the
  671. trailing '\0' is reinserted and kill the trailing blanks in each element.
  672.  
  673. - SUMMARY: STRING(V) arguments are blank padded during the call to the FORTRAN
  674. routine, but remain original in the C code. (P)STRINGV arguments are blank
  675. padded for the FORTRAN call, and after returning from FORTRAN trailing blanks
  676. are stripped off.
  677.  
  678.  
  679. 5. (P)ZTRINGV:
  680. - (P)ZTRINGV - is identical to (P)STRINGV, except that the dimensions of the
  681. array of strings is explicitly specified, [users of (P)ZTRINGV should examine
  682. cfortest.c for a working example.]:
  683.  
  684. - (P)ZTRINGV must replace (P)STRINGV wherever the sizeof() can't be used to
  685. determine the dimensions of the vector of strings. e.g. when calling FORTRAN
  686. from C with a char[][] which the C routine receives as an argument.
  687.  
  688. - To specify the numbers of elements:
  689. #define routine_name_ELEMS_j   ZTRINGV_ARGS(k)       
  690.                                  [..ARGS for subroutines, ..ARGF for functions.]
  691. or
  692. #define routine_name_ELEMS_j   ZTRINGV_NUM(l)
  693. Where: routine_name is as above.
  694.        j            [1-n], is the argument being specifying.
  695.        k            [1-n], the value of this argument is the dynamic number of 
  696.                     elements for argument j. The argument must be of type 
  697.                     (P)BYTE, (P)DOUBLE, (P)FLOAT, (P)INT, (P)LONG or (P)SHORT.
  698.        l            the number of elements for argument j. This must be an
  699.                     integer constant available at compile time.
  700.                     i.e. it is static.
  701.  
  702. - Similarly to specify the useful length, [i.e. don't count C's trailing '\0',]
  703. of each element:
  704. #define routine_name_ELEMLEN_j ZTRINGV_ARGS(m)
  705.                                  [..ARGS for subroutines, ..ARGF for functions.]
  706. or
  707. #define routine_name_ELEMLEN_j ZTRINGV_NUM(q)
  708. Where: m            [1-n], as for k but this is the length of each element. 
  709.        q            as for l but this is the length of each element. 
  710.  
  711.  
  712. 6. PVOID, as noted above, is used to declare that a function will be passed as
  713. an argument. In order to perform the call, cfortran.h must know the language of
  714. the function to be passed, therefore when passing the C functions to FORTRAN
  715. routines use: [Note the case of somefunction.]
  716.  
  717.     FORTRAN_ROUTINE(arg1, .... ,       
  718.                     C_FUNCTION(SOME_C_FUNCTION,some_c_function),
  719.                     ...., argn);
  720.  
  721. and similarly when passing a FORTRAN routine:
  722.  
  723.     FORTRAN_ROUTINE(arg1, .... , 
  724.                     FORTRAN_FUNCTION(SOME_FORT_FUNCTION,some_fort_function),
  725.                     ...., argn);
  726.  
  727. Note that if fcallsc has been redefined, the same definition of fcallsc used
  728. when creating the wrapper for 'some_c_function', must also be defined when
  729. C_FUNCTION is used. See ii) 4. of this section for why and how to redefine
  730. fcallsc.
  731.  
  732.  
  733. 7. CRAY only: 
  734. In a given piece of source code, where FFUNC is any FORTRAN routine,
  735. FORTRAN_FUNCTION(FFUNC,ffunc)
  736. disallows a previous 
  737. #define FFUNC(..) CCALLSFSUBn(FFUNC,ffunc,...) [ or CCALLSFFUNn]
  738. in order to make the UPPER CASE FFUNC callable from C.
  739. #define Ffunc(..) ... is OK though, as are obviously any other names.
  740.  
  741.  
  742. ii) Calling C routines from FORTRAN:
  743.     --------------------------------
  744.  
  745. Note that each of the following two statements to export a C routine to FORTRAN
  746. create FORTRAN 'wrappers', written in C, which must be compiled and linked
  747. along with the original C routines and with the FORTRAN calling code.
  748.  
  749. FORTRAN callable 'wrappers' may also be created for C macros. i.e. in this
  750. section, the term 'C function' may be replaced by 'C macro'.
  751.  
  752. for C functions returning void:
  753. FCALLSCSUBn(             Routine_name,ROUTINE_NAME,routine_name,argtype_1,...,argtype_n)
  754.  
  755. for all other C functions:
  756. FCALLSCFUNn(routine_type,Routine_name,ROUTINE_NAME,routine_name,argtype_1,...,argtype_n)
  757.  
  758. Where:
  759. 'n' = 0->10 (easily expanded to > 10) stands for the number of arguments to the 
  760.     routine.
  761. Routine_name = the C       name of the routine. [see 4. below]
  762. ROUTINE_NAME = the FORTRAN name of the routine (IN UPPER CASE LETTERS).
  763. routine_name = the FORTRAN name of the routine (IN lower case LETTERS).
  764. routine_type = the type of argument returned by C functions.
  765.              = BYTE, DOUBLE, FLOAT, INT, LOGICAL, LONG, SHORT, STRING, VOID.
  766.                [Instead of VOID, FCALLSCSUBn is recommended.]
  767. argtype_i    = the type of argument passed to the FORTRAN routine and must be
  768.                consistent in the definition and prototyping of the routine
  769.              = BYTE, DOUBLE, FLOAT, INT, LOGICAL, LONG, SHORT, STRING.
  770.              For vectors, i.e. 1 dim. arrays use 
  771.              = BYTEV, DOUBLEV, FLOATV, INTV, LOGICALV, LONGV, SHORTV, STRINGV.
  772.              For vectors of vectors, 2 dim. arrays use
  773.              = BYTEVV, DOUBLEVV, FLOATVV, INTVV, LOGICALVV, LONGVV, SHORTVV.
  774.              For n-dim. arrays use [currently implement n=1,2. n>2 easily done.]
  775.              = BYTEV..nV's..V, DOUBLEV..V, FLOATV..V, INTV..V, LOGICALV..V, 
  776.                LONGV..V, SHORTV..V.
  777.              For routines changing the values of an argument, the keyword is 
  778.                   prepended by a 'P'.
  779.              = PBYTE, PDOUBLE, PFLOAT, PINT, PLOGICAL, PLONG, PSHORT, 
  780.                PSTRING, PSTRINGV, PVOID.
  781.              For exceptional arguments which require no massaging to fit the
  782.                   argument passing mechanisms use:
  783.              = PVOID.
  784.                 This is most useful for passing functions as arguments.
  785.  
  786.  
  787. Notes:
  788.  
  789. 1. FCALLSCSUB/FUNn expect that the routine to be 'wrapped' has been properly
  790. prototyped, or at least declared.
  791.  
  792.  
  793. 2. cfortran.h may be expanded to handle a new argument type not already among
  794. the above. 
  795.  
  796.  
  797. 3. <BYTE|DOUBLE|BYTE|DOUBLE|FLOAT|INT|LOGICAL|LONG|SHORT><V|VV|VVV|...>
  798.  
  799. cfortran.h encourages the exact specification of the type and dimension of
  800. array parameters because it allows the C compiler to detect errors in the
  801. arguments when declaring the routine using FCALLSCSUB/FUNn, assuming the
  802. routine to be 'wrapped' has been properly prototyped.
  803.  
  804. cfortran.h does not strictly require the exact specification since the argument 
  805. is merely the address of the array and is passed on to the calling routine.
  806. Any array parameter could be declared as PVOID, but this circumvents
  807. C's compiletime ability to check the correctness of arguments and is therefore
  808. discouraged.
  809.  
  810. Passing the address of these arguments implies that PBYTEV, PFLOATV, ... ,
  811. PDOUBLEVV, ... don't exist in cfortran.h, since by default the routine and the
  812. calling code share the same array, i.e. the same values at the same memory
  813. location.
  814.  
  815. These comments do NOT apply to arrays of (P)STRINGV. For these parameters,
  816. cfortran.h passes a massaged copy of the array to the routine. When the routine
  817. returns, STRINGV ignores the copy, while PS/ZTRINGV replaces the calling
  818. code's original array with copy, which may have been modified by the called
  819. routine.
  820.  
  821.  
  822. 4. (P)STRING arguments have any trailing blanks removed before being passed to
  823. C, the same holds true for each element in (P)STRINGV. Space is malloc'd in all
  824. cases big enough to hold the original string (elements) as well as C's
  825. terminating '\0'. i.e. The useful size of the string (elements) is the same in
  826. both languages. PSTRING(V) => the string (elements) will be copied from the
  827. malloc'd space back into the FORTRAN bytes.
  828.  
  829.  
  830. 5. (P)STRING's, [NOT (P)STRINGV's,] behavior may be overridden in two cases. 
  831. In both cases PSTRING and STRING behave identically.
  832.  
  833. a) If a (P)STRING argument is 'effectively' the INTEGER 0, the NULL pointer is
  834. passed to the C routine. Since cfortran.h is expecting a string for this
  835. parameter, FORTRAN may not simply pass the integer 0, but must instead pass a
  836. string EQUIVALENCEd to the integer.              [See the example below.]
  837.  
  838. b) If the characters of a (P)STRING argument contain at least one HEX-00, i.e.
  839. the NUL character, i.e. C strings' terminating '\0', the address of the string
  840. is simply passed to the C routine. Therefore the C routine and the FORTRAN
  841. calling code share the same string at the same memory location. If the C
  842. routine modifies the string, the string will also be modified for the FORTRAN
  843. calling code.                                    [See the example below.]
  844. This mechanism is provided for two reasons:
  845.    - Some C routines require the string to exist at the given memory location, 
  846.      after the C routine has exited. Recall that for the normal mechanism, a 
  847.      copy of the FORTRAN string is given to the C routine, and this copy ceases
  848.      to exist after returning to the FORTRAN calling code.
  849.    - This mechanism saves runtime CPU cycles, since it doesn't malloc, copy and
  850.      kill trailing blanks of the string to be passed.
  851.      Only in a small minority of cases does the benefit of the saved CPU cycles
  852.      outweigh the programming effort required to manipulate the NUL character
  853.      in FORTRAN code.
  854. Mechanism a) overrides this mechanism. Therefore, if you wish to use this
  855. mechanism to pass the NULL string, "", to C, the first character of the string
  856. must obviously be the NUL character, but of the first n characters in the
  857. string, where n = sizeof(int), at least one must not be HEX-00.
  858.  
  859. Example:
  860. C FORTRAN                         /* C */
  861.       character*40 str            #include "cfortran.h"
  862. C Setting up a NULL as :          void cs(char *s) {if (s) printf("%s.\n",s);}
  863. C    i)  NUL character.           FCALLSCSUB1(cs,CS,cs,STRING)
  864. C    ii) NULL pointer.
  865.       integer inull           
  866.       character*1 NULL        
  867.       equivalence (NULL,inull)
  868.       inull=0                 
  869.  
  870.       data str/'just some string'/
  871. C Passing the NULL pointer to cs.
  872.       call cs(NULL)
  873. C Passing a copy of 'str' to cs.
  874.       call cs(str)
  875. C Passing address of 'str' to cs. Trailing blanks NOT killed.
  876.       str(40:) = NULL
  877.       call cs(str)
  878.       end
  879.  
  880.  
  881. 6. THE FOLLOWING INSTRUCTIONS ARE NOT REQUIRED FOR VAX VMS
  882.                                   ------------
  883. (P)STRINGV information [NOT required for VAX VMS]: cfortran.h cannot convert
  884. the FORTRAN vector of STRINGS to the required C vector of STRINGS without
  885. explicitly knowing the number of elements in the vector. The application must
  886. do one of the following for each (P)STRINGV argument in a routine before that
  887. routine's FCALLSCFUNn/SUBn is called:
  888.  
  889. #define routine_name_STRV_Ai NUM_ELEMS(j)
  890.  or
  891. #define routine_name_STRV_Ai NUM_ELEM_ARG(k)
  892.  or
  893. #define routine_name_STRV_Ai TERM_CHARS(l,m)
  894.  
  895. where: routine_name     is as above.
  896.        i [i=1->n.]      specifies the argument number of a STRING VECTOR.
  897.        j                would specify a fixed number of elements. 
  898.        k [k=1->n. k!=i] would specify an integer argument which specifies the
  899.                         number of elements.
  900.        l [char]         the terminating character at the beginning of an
  901.                         element, indicating to cfortran.h that the preceding
  902.                         elements in the vector are the valid ones.
  903.        m [m=1-...]      the number of terminating characters required to appear
  904.                         at the beginning of the terminating string element.
  905.                         Note that the terminating element is NOT passed on to
  906.                         the C routine.
  907.  
  908. e.g.      #define ce_STRV_A1 TERM_CHARS(' ',2)
  909.           FCALLSCSUB1(ce,CE,ce,STRINGV)
  910.  
  911. cfortran.h will pass on all elements, in the 1st and only argument to the C
  912. routine ce, of the STRING VECTOR until, but not including, the first string
  913. element beginning with 2 blank, ' ', characters.
  914.  
  915.  
  916. 7. INSTRUCTIONS REQUIRED ONLY FOR FORTRAN COMPILERS WHICH GENERATE
  917.                 -------------     
  918.    ROUTINE NAMES WHICH ARE UNDISTINGUISHABLE FROM C ROUTINE NAMES
  919.    i.e. VAX VMS 
  920.         HP9000
  921.         IBM RS/6000 if not using the -qextname option
  922.    Call them the same_namespace compilers.
  923.  
  924. FCALLSCSUBn(...) and FCALLSCFUNn(...), when compiled, are expanded into
  925. 'wrapper' functions, so called because they wrap around the original C 
  926. functions and interface the format of the original C functions' arguments and
  927. return values with the format of the FORTRAN call.
  928.  
  929. Ideally one wants to be able to call the C routine from FORTRAN using the same
  930. name as the original C name. This is not a problem for FORTRAN compilers which
  931. append an underscore, '_', to the names of routines, since the original C
  932. routine has the name 'name', and the FORTRAN wrapper is called 'name_'.
  933. Similarly, if the FORTRAN compiler generates upper case names for routines, the
  934. original C routine 'name' can have a wrapper called 'NAME', [Assuming the C
  935. routine name is not in upper case.] For these compilers, e.g. Mips, CRAY, IBM
  936. RS/6000 with the -qextname option, the naming of the wrappers is done
  937. automatically.
  938.  
  939. For same_namespace compilers things are not as simple, but cfortran.h tries to
  940. provide tools and guidelines to minimize the costs involved in meeting their
  941. constraints. The following two options can provide same_namespace compilers
  942. with distinct names for the wrapper and the original C function.
  943.  
  944. These compilers are flagged by cfortran.h with the CF_SAME_NAMESPACE  constant,
  945. so that the change in the C name occurs only when required.
  946.  
  947. For the remainder of the discussion, routine names generated by FORTRAN
  948. compilers are referred to in lower case, these names should be read as upper
  949. case for the appropriate compilers.
  950.  
  951.  
  952. HP9000:
  953. Note that f77 has a -U option which forces uppercase external names to be
  954. generated. Unfortunately, cc does not handle recursive macros. Hence, if one
  955. wished to use -U for separate C and FORTRAN namespaces, one would have to adopt
  956. a different convention of naming the macros which allow C to call FORTRAN
  957. subroutines. (Functions are not a problem.) The macros are currently the
  958. uppercase of the original FORTRAN name, and would have to be changed to
  959. lower case or mixed case, or to a different name. (Lower case would of course
  960. cause conflicts on many other machines.) Therefore, it is suggested that f77 -U 
  961. not be used, and instead that Option a) or Option b) outlined below be used.
  962.  
  963.  
  964. VAX/VMS:
  965. For the name used by FORTRAN in calling a C routine to be the same as that of
  966. the C routine, the source code of the C routine is required. A preprocessor
  967. directive can then force the C compiler to generate a different name for the C
  968. routine. 
  969. e.g.                #if defined(vms)
  970.                     #define name name_
  971.                     #endif
  972.                     void name() {printf("name: was called.\n");}
  973.                     FCALLSCSUB0(name,NAME,name)
  974.  
  975. In the above, the C compiler generates the original routine with the name
  976. 'name_' and a wrapper called 'NAME'. This assumes that the name of the
  977. routine, as seen by the C programmer, is not in upper case. Note that the VAX
  978. VMS linker is not case sensitive, allowing cfortran.h to export the upper case
  979. name as the wrapper, which then doesn't conflict with the routine name in C.
  980. Since the IBM and the HP have case sensitive linkers this technique is not
  981. available to them.
  982.  
  983. The above technique is required even if the C name is in mixed case, see 
  984. Option a) for the other compilers, but is obviously not required when 
  985. Option b) is used.
  986.  
  987.  
  988. Option a) Mixed Case names for the C routines to be called by FORTRAN.
  989.  
  990. If the original C routines have mixed case names, there are no name space
  991. conflicts.
  992.  
  993. Note that for VAX/VMS, the technique outlined above must also used.
  994.  
  995.  
  996. Option b) Modifying the names of C routines when used by FORTRAN:
  997.  
  998. The more robust naming mechanism, which guarantees portability to all machines, 
  999. 'renames' C routines when called by FORTRAN. Indeed, one must change the names
  1000. on same_namespace compilers when FORTRAN calls C routines for which the source
  1001. is unavailable. [Even when the source is available, renaming may be preferable
  1002. to Option a) for large libraries of C routines.]
  1003.  
  1004. Obviously, if done for a single type of machine, it must be done for all
  1005. machines since the names of routines used in FORTRAN code cannot be easily
  1006. redefined for different machines.
  1007.  
  1008. The simplest way to achieve this end is to do explicitly give the modified
  1009. FORTRAN name in the FCALLSCSUBn(...) and FCALLSCFUNn(...) declarations. e.g.
  1010.  
  1011. FCALLSCSUB0(name,CFNAME,cfname)
  1012.  
  1013. This allows FORTRAN to call the C routine 'name' as 'cfname'. Any name can of
  1014. course be used for a given routine when it is called from FORTRAN, although
  1015. this is discouraged due to the confusion it is sure to cause.  e.g. Bizarre,
  1016. but valid and allowing C's 'call_back' routine to be called from FORTRAN as
  1017. 'abcd':
  1018.  
  1019. FCALLSCSUB0(call_back,ABCD,abcd)
  1020.  
  1021.  
  1022. cfortran.h also provides preprocessor directives for a systematic 'renaming' of
  1023. the C routines when they are called from FORTRAN. This is done by redefining
  1024. the fcallsc macro before the FCALLSCSUB/FUN/n declarations as follows:
  1025.  
  1026. #undef  fcallsc
  1027. #define fcallsc(UN,LN) preface_fcallsc(CF,cf,UN,LN)
  1028.  
  1029. FCALLSCSUB0(hello,HELLO,hello)
  1030.  
  1031. Will cause C's routine 'hello' to be known in FORTRAN as 'cfhello'. Similarly
  1032. all subsequent FCALLSCSUB/FUN/n declarations will generate wrappers to allow
  1033. FORTRAN to call C with the C routine's name prefaced by 'cf'. The following has
  1034. the same effect, with subsequent FCALLSCSUB/FUN/n's appending the modifier to
  1035. the original C routines name.
  1036.  
  1037. #undef  fcallsc
  1038. #define fcallsc(UN,LN) append_fcallsc(Y,y,UN,LN)
  1039.  
  1040. FCALLSCSUB0(Xroutine,ROUTINE,routine)
  1041.  
  1042. Hence, C's Xroutine is called from FORTRAN as:
  1043.        CALL XROUTINEY()
  1044.  
  1045. The original behavior of FCALLSCSUB/FUN/n, where FORTRAN routine names are left
  1046. identical to those of C, is returned using:
  1047.  
  1048. #undef  fcallsc
  1049. #define fcallsc orig_fcallsc
  1050.  
  1051.  
  1052. In C, when passing a C routine, i.e. its wrapper, as an argument to a FORTRAN
  1053. routine, the FORTRAN name declared is used and the correct fcallsc must be in
  1054. effect. E.g. Passing 'name' and 'routine' of the above examples to the FORTRAN
  1055. routines, FT1 and FT2, respectively:
  1056.  
  1057. #undef  fcallsc                  /* This might not be needed            */
  1058. #define fcallsc orig_fcallsc     /* if fcallsc is already orig_fcallsc. */
  1059. FT1(C_FUNCTION(CFNAME,cfname));
  1060.  
  1061. #undef  fcallsc
  1062. #define fcallsc(UN,LN) append_fcallsc(Y,y,UN,LN)
  1063. FT1(C_FUNCTION(XROUTINE,xroutine));
  1064.  
  1065. Note that if the names of C routines are modified when used by FORTRAN, fcallsc
  1066. would usually be defined once in a header_file.h for the application. This
  1067. definition would then be used and be valid for the entire application and
  1068. fcallsc would at no point need to be redefined.
  1069.  
  1070.  
  1071. ONCE AGAIN: THE DEFINITIONS, INSTRUCTIONS, DECLARATIONS AND DIFFICULTIES
  1072. DESCRIBED HERE, NOTE 4. of II ii), APPLY ONLY FOR VAX VMS, THE IBM RS/6000
  1073. WITHOUT THE -qextname OPTION, OR HP-UX FORTRAN AND APPLY ONLY WHEN CREATING
  1074. WRAPPERS WHICH ENABLE FORTRAN TO CALL C ROUTINES.
  1075.  
  1076.  
  1077.  
  1078. iii) Using C to manipulate FORTRAN COMMON BLOCKS:
  1079.      -------------------------------------------------------
  1080.  
  1081. FORTRAN common blocks are set up with the following two constructs:
  1082.  
  1083. #define Common_block_name COMMON_BLOCK(COMMON_BLOCK_NAME,common_block_name)
  1084.  
  1085. Common_block_name is in UPPER CASE. 
  1086. COMMON_BLOCK_NAME is in UPPER CASE.
  1087. common_block_name is in lower case. 
  1088. [Common_block_name actually follows the same 'rules' as Routine_name in Note 2.
  1089. of II i).] This construct exists to ensure that C code accessing the common
  1090. block is machine independent.
  1091.  
  1092. COMMON_BLOCK_DEF(TYPEDEF_OF_STRUCT, Common_block_name);
  1093.  
  1094. where 
  1095. typedef { ... } TYPEDEF_OF_STRUCT;
  1096. declares the structure which maps on to the common block. The #define of
  1097. Common_block_name must come before the use of COMMON_BLOCK_DEF.
  1098.  
  1099.  
  1100. C programs can place a string (or a multidimensional array of strings) into a
  1101. FORTRAN common block using the following call:
  1102.  
  1103. C2FCBSTR( CSTR, FSTR,DIMENSIONS);
  1104.  
  1105. where:
  1106.  
  1107. CSTR is a pointer to the first element of C's copy of the string (array). 
  1108.      The C code must use a duplicate of, not the original, common block string,
  1109.      because the FORTRAN common block does not allocate space for C strings'
  1110.      terminating '\0'.
  1111.  
  1112. FSTR is a pointer to the first element of the string (array) in the common
  1113.      block.
  1114.  
  1115. DIMENSIONS is the number of dimensions of string array. 
  1116.      e.g. char a[10]      has DIMENSIONS=0.
  1117.           char aa[10][17] has DIMENSIONS=1.
  1118.           etc...
  1119.  
  1120. C2FCBSTR will copy the string (array) from CSTR to FSTR, padding with blanks, 
  1121. ' ', the trailing characters as required. C2FCBSTR uses DIMENSIONS and FSTR to
  1122. determine the lengths of the individual string elements and the total number of
  1123. elements in the string array.
  1124.  
  1125. Note that:
  1126. - the number of string elements in CSTR and FSTR are identical.
  1127. - for arrays of strings, the useful lengths of strings in CSTR and FSTR must be
  1128.   the same. i.e. CSTR elements each have 1 extra character to accommodate the
  1129.   terminating '\0'.
  1130. - On most non-ANSI compilers, the DIMENSION argument cannot be prepended by any
  1131.   blanks.
  1132.  
  1133.  
  1134. FCB2CSTR( FSTR, CSTR,DIMENSIONS)
  1135.  
  1136. is the inverse of C2FCBSTR, and shares the same arguments and caveats. Note
  1137. that FCB2CSTR copies each string element of FSTR to CSTR, minus FORTRAN
  1138. strings' trailing blanks.
  1139.  
  1140.  
  1141. cfortran.h USERS ARE STRONGLY URGED TO EXAMINE THE COMMON BLOCK EXAMPLES IN
  1142. CFORTEST.C AND CFORTEX.FOR. The use of strings in common blocks is
  1143. demonstrated, along with a suggested way for C to imitate FORTRAN EQUIVALENCE'd
  1144. variables.
  1145.  
  1146.  
  1147.               ===> USERS OF CFORTRAN.H NEED READ NO FURTHER <===
  1148.  
  1149.  
  1150. III Some Musings
  1151. ----------------
  1152.  
  1153. cfortran.h is simple enough to be used by the most basic of applications, i.e.
  1154. making a single C/FORTRAN routine available to the FORTRAN/C programmers. Yet
  1155. cfortran.h is powerful enough to easily make entire C/FORTRAN libraries
  1156. available to FORTRAN/C programmers. 
  1157.  
  1158.  
  1159. cfortran.h is the ideal tool for FORTRAN libraries which are being (re)written
  1160. in C, but are to (continue to) support FORTRAN users. It allows the routines to
  1161. be written in 'natural C', without having to consider the FORTRAN argument
  1162. passing mechanisms of any machine. It also allows C code accessing these
  1163. rewritten routines, to use the C entry point. Without cfortran.h, one risks the
  1164. perverse practice of C code calling a C function using FORTRAN argument passing
  1165. mechanisms!
  1166.  
  1167.  
  1168. Perhaps the philosophy and mechanisms of cfortran.h could be used and extended
  1169. to create other language bridges such as ADAFORTRAN, CPASCAL, COCCAM, etc.
  1170.  
  1171.  
  1172. The code generation machinery inside cfortran.h, i.e. the global structure is
  1173. quite good, being clean and workable as seen by its ability to meet the needs
  1174. and constraints of many different compilers. Though the individual instructions
  1175. of the A..., C..., T..., R... and K... tables deserve to be cleaned up.
  1176.  
  1177.  
  1178.  
  1179. IV  Getting Serious with cfortran.h
  1180. -----------------------------------
  1181.  
  1182. cfortran.h is set up to be as simple as possible for the casual user. While
  1183. this ease of use will always be present, 'hooks', i.e. preprocessor directives,
  1184. are required in cfortran.h so that some of the following 'inefficiencies' can
  1185. be eliminated if they cause difficulties:
  1186.  
  1187. o cfortran.h contains a few small routines for string manipulation. These
  1188. routines are declared static and are included and compiled in all source code
  1189. which uses cfortran.h. Hooks should be provided in cfortran.h to create an
  1190. object file of these routines, allowing cfortran.h to merely prototypes
  1191. these routines in the application source code. This is the only 'problem' which
  1192. afflicts both halves of cfortran.h. The remaining discussion refers to the C
  1193. calls FORTRAN half only.
  1194.  
  1195. o Similar to the above routines, cfortran.h generates code for a 'wrapper'
  1196. routine for each FUNCTION exported from FORTRAN. Again cfortran.h needs
  1197. preprocessor directives to create a single object file of these routines,
  1198. and to merely prototype them in the applications.
  1199.  
  1200. o Libraries often contain hundreds of routines. While the preprocessor makes
  1201. quick work of generating the required interface code from cfortran.h and the
  1202. application.h's, it may be convenient for very large stable libraries to have
  1203. final_application.h's which already contain the interface code, i.e. these
  1204. final_application.h's would not require cfortran.h. [The convenience can be
  1205. imagined for the VAX VMS CC compiler which has a fixed amount of memory for
  1206. preprocessor directives. Not requiring cfortran.h, with its hundreds of
  1207. directives, could help prevent this compiler from choking on its internal
  1208. limits quite so often.]
  1209.  
  1210. With a similar goal in mind, note that cfortran.h defines 100's of preprocessor
  1211. directives. There is always the potential that these will clash with other tags
  1212. in the users code, so final_applications.h, which don't require cfortran.h,
  1213. also provide the solution.
  1214.  
  1215. In the same vein, routines with more than 14 arguments can not be interfaced by
  1216. cfortran.h with compilers which limit C macros to 31 arguments. To resolve this
  1217. difficulty, final_application.h's can be created on a compiler without this
  1218. limitation.
  1219.  
  1220. Therefore, new machinery is required to do:
  1221.  
  1222. application.h + cfortran.h => final_application.h
  1223.  
  1224. The following example may help clarify the means and ends:
  1225.  
  1226. If the following definition of the HBOOK1 routine, note the
  1227. /*commented_out_part*/, is passed through the preprocessor [perhaps #undefing
  1228. and #defining preprocessor constants if creating an application.h for
  1229. compiler other than that of the preprocessor being used, 
  1230. e.g. cpp -Umips -DCRAY ... ] :
  1231.  
  1232. #include "cfortran.h"
  1233. /*#define HBOOK1(ID,CHTITLE,NX,XMI,XMA,VMX)                 \*/
  1234.      CCALLSFSUB6(HBOOK1,hbook1,INT,STRING,INT,FLOAT,FLOAT,FLOAT, \
  1235.                  ID,CHTITLE,NX,XMI,XMA,VMX) 
  1236.  
  1237. Interface code is produced, based on the 'variables', 
  1238. ID,CHTITLE,NX,XMI,XMA,VMX, which will correctly massage a HBOOK1 call.
  1239. Therefore, adding the #define line:
  1240.  
  1241. #define HBOOK1(ID,CHTITLE,NX,XMI,XMA,VMX)                 \
  1242.  'interface_code'(ID,CHTITLE,NX,XMI,XMA,VMX)
  1243.  
  1244. which is placed into final_application.h.
  1245.  
  1246. The only known limitation of the above method does not allow the 'variable'
  1247. names to include B1,B2,...,B9,BA,BB,... 
  1248.  
  1249. Obviously the machinery to automatically generate final_applications.h from
  1250. cfortran.h and applications.h needs more than just some preprocessor
  1251. directives, but a fairly simple unix shell script should be sufficient. Any
  1252. takers?
  1253.  
  1254.  
  1255.  
  1256. V Machine Dependencies of cfortran.h
  1257. ------------------------------------
  1258.  
  1259. Porting cfortran.h applications, e.g. the hbook.h and cstring.c mentioned
  1260. above, to other machines is trivial since they are machine independent. Porting
  1261. cfortran.h requires a solid knowledge of the new machines C preprocessor, and
  1262. its FORTRAN argument passing mechanisms. Logically cfortran.h exists as two
  1263. halves, a "C CALLS FORTRAN" and a "FORTRAN CALLS C" utility. In some cases it
  1264. may be perfectly reasonable to port only 'one half' of cfortran.h onto a new
  1265. system.
  1266.  
  1267.  
  1268. The lucky programmer porting cfortran.h to a new machine, must discover the
  1269. FORTRAN argument passing mechanisms. A safe starting point is to assume that
  1270. variables and arrays are simply passed by reference, but nothing is guaranteed.
  1271. Strings, and n-dimensional arrays of strings are a different story. It is
  1272. doubtful that any systems do it quite like VAX VMS does it, so that a UNIX or
  1273. f2c versions may provide an easier starting point.
  1274.  
  1275.  
  1276. cfortran.h uses and abuses the preprocessor's ## operator. Although the ##
  1277. operator does not exist in many compilers, many kludges do. cfortran.h uses
  1278. /**/ with no space allowed between the slashes, '/', and the macros or tags
  1279. to be concatenated. e.g.
  1280. #define concat(a,b) a/**/b   /* works*/
  1281. main()
  1282. {
  1283.   concat(pri,ntf)("hello");           /* e.g. */
  1284. }
  1285. N.B. On some compilers without ##, /**/ may also not work. The author may be
  1286. able to offer alternate kludges.
  1287.  
  1288.  
  1289.  
  1290. VI History and Acknowledgements
  1291. -------------------------------
  1292.  
  1293. 1.0 - Supports VAX VMS using C 3.1 and FORTRAN 5.4.                    Oct. '90.
  1294. 1.0 - Supports Silicon Graphics w. Mips Computer 2.0 f77 and cc.       Feb. '91.
  1295.           [Port of C calls FORTRAN half only.]
  1296. 1.1 - Supports Mips Computer System 2.0 f77 and cc.                    Mar. '91.
  1297.           [Runs on at least: Silicon Graphics IRIX 3.3.1
  1298.                              DECstations with Ultrix V4.1]
  1299. 1.2 - Internals made simpler, smaller, faster, stronger.               May  '91.
  1300.     - Mips version works on IBM RS/6000, this is now called the unix version.
  1301. 1.3 - UNIX and VAX VMS versions are merged into a single cfortran.h.   July '91.
  1302.     - C can help manipulate (arrays of) strings in FORTRAN common blocks.
  1303.     - Dimensions of string arrays arguments can be explicit.
  1304.     - Supports Apollo DomainOS 10.2 (sys5.3) with f77 10.7 and cc 6.7.
  1305.  
  1306. 2.0 - Improved code generation machinery creates K&R or ANSI C.        Aug. '91.
  1307.     - Supports Sun, CRAY. f2c with vcc on VAX Ultrix.
  1308.     - cfortran.h macros now require routine and COMMON block names in both 
  1309.       upper and lower case. No changes required to applications though.
  1310.     - PROTOCCALLSFSUBn is eliminated, with no loss to cfortran.h performance.
  1311.     - Improved tools and guidelines for naming C routines called by FORTRAN.
  1312. 2.1 - LOGICAL correctly supported across all machines.                 Oct. '91.
  1313.     - Improved support for DOUBLE PRECISION on the CRAY.
  1314.     - HP9000 fully supported.
  1315.     - VAX Ultrix cc or gcc with f77 now supported.
  1316. 2.2 - SHORT, i.e. INTEGER*2, and BYTE now supported.                   Dec. '91.
  1317.     - LOGICAL_STRICT introduced. More compact and robust internal tables.
  1318.     - typeV and typeVV for type = BYTE, DOUBLE, FLOAT, INT, LOGICAL, LONG,SHORT.
  1319.     - FORTRAN passing strings and NULL pointer to C routines improved. 
  1320. 2.3 - Extraneous arguments removed from many internal tables.          May  '92.
  1321.     - Introduce pseudo argument type SIMPLE for user defined types.
  1322.     - LynxOS using f2c supported. (Tested with LynxOS 2.0 386/AT.)
  1323. 2.4 - Separation of internal C and Fortran compilation directives.     Oct. '92.
  1324.     - f2c and NAG f90 supported on all machines.
  1325.  
  1326. ['Support' implies these and more recent releases of the respective
  1327. OS/compilers/linkers can be used with cfortran.h. Earlier releases may also
  1328. work.]
  1329.  
  1330.  
  1331. Acknowledgements:
  1332. M.L.Luvisetto (Istituto Nazionale Fisica Nucleare - Centro Nazionale
  1333. Analisi Fotogrammi, Bologna, Italy) provided all the support for the port to
  1334. the CRAY. Marisa's encouragement and enthusiasm was also much appreciated.
  1335.  
  1336.  
  1337.  
  1338. THIS PACKAGE, I.E. CFORTRAN.H, THIS DOCUMENT, AND THE CFORTRAN.H EXAMPLE
  1339. PROGRAMS ARE PROPERTY OF THE AUTHOR WHO RESERVES ALL RIGHTS. THIS PACKAGE AND
  1340. THE CODE IT PRODUCES MAY BE FREELY DISTRIBUTED WITHOUT FEES, SUBJECT TO THE
  1341. FOLLOWING RESTRICTIONS:
  1342. - YOU MUST ACCOMPANY ANY COPIES OR DISTRIBUTION WITH THIS (UNALTERED) NOTICE.
  1343. - YOU MAY NOT RECEIVE MONEY FOR THE DISTRIBUTION OR FOR ITS MEDIA 
  1344.   (E.G. TAPE, DISK, COMPUTER, PAPER.)
  1345. - YOU MAY NOT PREVENT OTHERS FROM COPYING IT FREELY.
  1346. - YOU MAY NOT DISTRIBUTE MODIFIED VERSIONS WITHOUT CLEARLY DOCUMENTING YOUR
  1347.   CHANGES AND NOTIFYING THE AUTHOR.
  1348. - YOU MAY NOT MISREPRESENTED THE ORIGIN OF THIS SOFTWARE, EITHER BY EXPLICIT
  1349.   CLAIM OR BY OMISSION.
  1350.  
  1351. THE INTENT OF THE ABOVE TERMS IS TO ENSURE THAT THE CFORTRAN.H PACKAGE NOT BE
  1352. USED FOR PROFIT MAKING ACTIVITIES UNLESS SOME ROYALTY ARRANGEMENT IS ENTERED
  1353. INTO WITH ITS AUTHOR.
  1354.               
  1355. THIS SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
  1356. EXPRESSED OR IMPLIED. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
  1357. SOFTWARE IS WITH YOU. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST
  1358. OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. THE AUTHOR IS NOT RESPONSIBLE
  1359. FOR ANY SUPPORT OR SERVICE OF THE CFORTRAN.H PACKAGE.
  1360.  
  1361.                                               Burkhard Burow 
  1362.                                               burow@vxdesy.cern.ch
  1363.  
  1364. P.S. Your comments and questions are welcomed and usually promptly answered.
  1365.  
  1366. VAX VMS and Ultrix, Silicon Graphics (SGI), DECstation, Mips RISC, Sun, CRAY,
  1367. IBM RS/6000, Apollo DomainOS, HP, LynxOS, f2c and NAG are registered trademarks.
  1368.         
  1369. /* end: cfortran.doc */
  1370.